\chapter{Architektura systemu}
\label{chap:architektura_systemu}
Niniejszy rozdział zawiera opis architektury systemu będącego przedmiotem tej pracy z uwzględnieniem wad i zalet wybranych rozwiązań. 
 
W aplikacji do zarządzania budżetem domowym została zastosowana architektura klient-serwer. Jest to rozproszona architektura, która zakłada podział ról pomiędzy serwer i~klientów. W architekturze tej serwer świadczy określone usługi lub zapewnia zasoby aplikacjom klienckim po otrzymania od nich żądania ich udostępnienia. Aplikacja kliencka może jednocześnie korzystać z usług wielu serwerów. Zasadniczą zaletą architektury klient-serwer jest zmniejszenie wielkości przesyłanych danych, ponieważ przez sieć przesyłane są jedynie odpowiedzi na konkretne pytania, a nie całe pliki, czy aplikacje do lokalnego wykonania.



  \section{Architektura aplikacji internetowej}
  \label{sec:architektura_aplikacji_internetowej}
Aplikacja budżetu domowego została zaimplementowana z użyciem wzorca projektowego MVP\footnote{MVP --- Model--Widok--Prezenter \ang{Model--View--Presenter}}. Jest to pochodna wzorca MVC \footnote{MVC --- Model--Widok--Kontroler \ang{Model--View--Controller}} ze zmianami odpowiedzialności poszczególnych modułów. Jest
on często wykorzystywany do tworzenia aplikacji posiadających graficzny
interfejs użytkownika, gdyż umożliwia podział programu na część zajmującą się interfejsem użytkownika (widok), część odpowiedzialną za logikę aplikacji(prezenter) oraz część reprezentującą dane (model). Przejrzysty rozdział odpowiedzialności modułów pozwala na efektywny i niezależny pracę wielu programistów nad rozwojem i testowaniem poszczególnych elementów składowych aplikacji. Wzorzec MVP wprowadza moduł prezentera w miejsce kontrolera ze wzorca MVC. Ponadto zakłada zmniejszenie znaczenia widoku na rzecz prezentera, który posiada pewną wiedzę o interfejsie użytkownika oraz o tym, jak odwzorować poszczególne akcje użytkownika na zmiany modelu i widoku. 

  \begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{obrazy/MVP2.pdf}
    \caption{Wzorzec MVP - Pasywny widok}
    \label{fig:mvp1}
  \end{figure}
  
Istnieją różne wersje wzorca MVP, dwie najczęściej używane określane są jako ,,Pasywny widok'' i ,,Nadzorujący kontroler''\cite{Fowler}. Obie wersje zakładają przejęcie przez prezentera głównej odpowiedzialności za logikę działania aplikacji. Pierwsza z nich wprowadza dodatkowo całkowite zerwanie powiązania między widokiem a modelem. Widok nie jest odpowiedzialny za samodzielną aktualizację - logika jego działania przeniesiona jest do kontrolera. Podejście to umożliwia prostsze testowanie aplikacji (testowanie złożonych interfejsów użytkownika często okazuje się pracochłonne i długotrwałe). Wadą tego rozwiązania jest zwiększenie skomplikowania implementacji prezentera. ,,Nadzorujący kontroler'' zakłada, że widok może bezpośrednio odnosić się do modelu poprzez mechanizm wiązania danych (ang. Data Binding) bez pośrednictwa prezentera. Prezenter aktualizuje widok jedynie wtedy, gdy logika zmiany widoku jest bardziej skomplikowana. W wyniku zachowania w widoku pewnej części logiki aplikacji, testowanie okazuje się trudniejsze w porównaniu do poprzedniego rozwiązania, w zamian implementacja prezentera jest bardziej przejrzysta.

  
    \begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{obrazy/MVP1.pdf}
    \caption{Wzorzec MVP - Nadzorujący kontroler}
    \label{fig:mvp2}
  \end{figure}


Efektywne testowanie aplikacji jest bardzo ważne podczas tworzenia każdego programu, chociaż jego rola jest często niedoceniana. Model ,,Pasywny widok'' w znacznym stopniu ułatwia odnajdywanie błędów i z tego powodu został wykorzystany podczas implementacji aplikacji budżetu domowego.  Dalszy opis odpowiedzialności modelu, widoku i prezentera odnosi jest jedynie do wybranego wybranego wariantu MVP.


  
    \subsection*{Model}
    Model reprezentuje dane aplikacji oraz powiązania i~zależności pomiędzy nimi. Na dane w~modelu składają się m.in.: informacje o transakcjach użytkownika (wydatkach, przychodach), kategoriach transakcji, inwestycjach giełdowych, lokatach, kredytach i planach oszczędzania. Moduł ten jest całkowicie niezależny od pozostałych części aplikacji, nie jest świadomy istnienia innych modułów, udostępnia jedynie interfejs, który określa sposób pobierania i~modyfikację przechowywanych danych. We wzorcu MVP widok nie ma połączenia z modelem. We wszelkich żądaniach operacji na danych pośredniczy prezenter.  
    
    \subsection*{Widok}
    Widok jest odpowiedzialny za wyświetlanie danych przekazanych z modelu i przekazywanie żądań użytkownika prezenterowi. Reaguje on na zajście zdarzeń, takich jak na przykład kliknięcie myszką na przycisk. Widok nie komunikuje się bezpośrednio z modelem, to prezenter obsługuje żądania widoku i w odpowiedzi ,,prezentuje'' mu dane. Poziom logiki, za którą odpowiedzialny jest widok, różni się pomiędzy różnymi implementacjami wzorca MVP. W radykalnym podejściu po każdym wywołaniu zdarzenia przez użytkownika, widok alarmuje prezentera, który następnie pobiera dane o zdarzeniu przy pomocy metod zdefiniowanych przez interfejs widoku. Bardziej swobodne podejście pozwala na wykonanie w widoku wstępnej analizy typu zdarzenia i jego parametrów, a następnie powiadomienie prezentera, jeżeli okaże się to konieczne do aktualizacji widoku. Podejście to umożliwia uniknąć przesadnej komplikacji sposobu przetwarzania żądań widoku po stronie prezentera.  
        
    \subsection*{Prezenter}
    
Wzorzec MVP wprowadza moduł prezentera w miejsce kontrolera ze wzorca MVC, który odpowiedzialny jest za wysyłanie do widoku wyników logiki biznesowej (w klasycznym wzorcu MVC rolę tą dzieliły kontroler oraz model). 
  
Zadaniem prezentera jest realizacja logiki aplikacji. Prezenter posiada powiązania do modelu i~widoku, aby móc sterować ich zachowaniem. Podstawowe zadania prezentera to aktualizacja widoków, zarządzanie historią i synchronizacja danych w modelu.
    
  \section{Architektura warstwy serwerowej}
  W części serwerowej aplikacji budżetu domowego zostało użyte mapowanie obiektowo-relacyjne \footnote{ORM --- mapowanie obiektowo-relacyjne \ang{Object-Relational Mapping}} wraz ze wzorcem DAO\footnote{DAO --- obiekt dostępu do danych \ang{Data Access Object}}.
  
  Mapowanie obiektowo-relacyjne umożliwia konwertowanie obiektów aplikacji na wiersze w tabelach bazy danych opartej na relacjach i na odwrót. Podejście to pozwala na wykorzystanie zalet relacyjnych baz danych bez rezygnacji z programowania obiektowego. Standard umożliwia znaczną redukcję czasu pracy nad konfiguracją dostępu do danych i uniezależnia od systemu zarządzającego bazą.
  
  Separacja danych zapisywanych do tabel od operacji wykonywanych na tych danych możliwa jest dzięki wprowadzeniu obiektów DTO \footnote{DTO --- obiekt transferujący dane \ang{Data Transfer Object}} i komponentów DAO. Obiekty DTO zawierają atrybuty, które będą zapisywane do bazy danych, zaś komponenty DAO zawierają metody, który są wykonywane na obiektach DTO (np. zapis do bazy danych, aktualizacja, usunięcie). Wzorzec DAO wprowadza przejrzyste rozdzielenie pomiędzy danymi a operacjami oraz dostarcza jednolity interfejs do komunikacji między aplikacją a źródłem danych.  
  

  \section*{Podsumowanie}
 W~tym rozdziale zostały opisane wzorce architektury, na których bazuje implementacja aplikacji do budżetu domowego zarówno w warstwie klienta, jak i serwera. Podczas opisu zostały uwzględnione wady i zalety wybranych rozwiązań. Przy wyborze wzorców i standardów kierowano się takimi aspektami jak: przejrzysty podział na niezależne, logiczne moduły, łatwość testowania, przenośność i uniwersalność rozwiązania. Analiza powyższych własności doprowadziła do wyboru wzorca architektury klient-serwer, wzorca MVP ,,Pasywny widok'' oraz mapowania obiektowo-relacyjnego i wzorca DAO w warstwie serwerowej.



\begin{comment}
OPIS ROZWIĄZANIA - NA JAKIM POZIOMIE SZCZEGÓŁOWOŚCI?
- struktura blokowa (układu, oprogramowania)
- funkcje poszczególnych modułów i~ich współdziałanie (interfejsy)
- wybrane rozwiązania szczegółowe (oryginalne, sprawiające
trudności, ...)
ale nie
- szczegółowy opis procedur i~struktur danych (poza szczególnymi
przypadkami), zmiennych wewnętrznych, ...
- schematy bramkowe (funkcje Boolowskie) wszystkich modułów
złożonego układu, ...
Bardziej szczegółowe informacje – w~załącznikach
- struktura logiczna układu
- kompletne wyniki weryfikacji (symulacji) i~testowania
- „instrukcja użytkownika”
Pełna dokumentacja (kod programu, ...) – na CD-ROMie
\end{comment}